BUG: Revert dlpack device#221
Conversation
dd2ae23 to
9490c92
Compare
|
Okay, this one is ready from my side. Please do check me, since it's a bit manual and not just a straight revert. |
9490c92 to
0458ff5
Compare
betatim
left a comment
There was a problem hiding this comment.
Two small comments.
Ideally we'd have a test that uses pytorch so that we encode that learning about DLPack device IDs into a test (as in: don't mess with them). Can we do that without having to install pytest? Maybe a test that no matter which array-api-strict device is used the device ID is always CPU?
| if copy is not _undef: | ||
| raise ValueError("The copy argument to from_dlpack requires at least version 2023.12 of the array API") | ||
|
|
||
| # Going to wait for upstream numpy support |
There was a problem hiding this comment.
I don't understand this comment :-/
There was a problem hiding this comment.
git blame attributes it to the very first PR from Aaron which brought the initial dlpack support. Not exactly sure what that referred to; at a guess, that was copy= which was not implemented in numpy at the time. Either way, since neither of us two knows what it refers to, I'll take it as a sign that the comment is no longer useful and drop it.
| assert x.device == y.device == z.device == CPU_DEVICE | ||
|
|
||
|
|
||
| @pytest.mark.parametrize( |
There was a problem hiding this comment.
We could keep this test no? It seems like it checks something that is somewhat related to the DLPack device ID but also not related.
I'd keep it (unless I'm missing something)
There was a problem hiding this comment.
An issue is that this test just did not work in 2.5? So if we're just reverting the change made in 2.6, the test is broken; if we also fix from_dlpack, that's not just a revert...
In [1]: import array_api_strict as xp
In [2]: xp.__version__
Out[2]: '2.5'
In [3]: a = xp.arange(3.0, device=xp.Device('device1'))
In [4]: xp.from_dlpack(a).device
Out[4]: array_api_strict.Device('CPU_DEVICE')
An attempt at a fix:
$ git diff
diff --git a/array_api_strict/_creation_functions.py b/array_api_strict/_creation_functions.py
index 685044d..5e40771 100644
--- a/array_api_strict/_creation_functions.py
+++ b/array_api_strict/_creation_functions.py
@@ -250,6 +250,8 @@ def from_dlpack(
_check_device(device)
else:
device = None
+ if hasattr(x, "device"):
+ device = x.device
if copy in [_undef, None]:
# numpy 1.26 does not have the copy= argLooks simple and correct, right?
array_api_strict/tests/test_creation_functions.py::test_from_dlpack_default_device FAILED [ 96%]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> traceback >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
def test_from_dlpack_default_device():
x = asarray([1, 2, 3])
y = from_dlpack(x)
z = from_dlpack(np.asarray([1, 2, 3]))
> assert x.device == y.device == z.device == CPU_DEVICE
E AssertionError: assert array_api_strict.Device('CPU_DEVICE') == 'cpu'
E + where array_api_strict.Device('CPU_DEVICE') = Array([1, 2, 3], dtype=array_api_strict.int64).device
E + and 'cpu' = Array([1, 2, 3], dtype=array_api_strict.int64, device=cpu).device
So one cannot just reuse the device of x, one has to map the device of x onto the device of array-api-strict! And the device naming is not standardized, so pretty much the only way to map them is via DLPACK enum value, but that's what we reverting here.
TBH I don't see a way out, do you @betatim ?
0458ff5 to
21b4404
Compare
|
In view of #221 (comment), my plan is to wait for a couple of days to see if somebody tells me I miss something simple; and if not, then land this PR and cut a 2.6.1 release. And then we'll be able to continue crafting dlpack improvements. |
closes gh-219
reverting gh-212 is a bit manual since after landing, things moved around between
_array_object.pyand_device.py